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ABSTRACT : 

CHG DATE=19990617 STATUS=0> The need for private copies of an 
interchange 

document file in a computer system is eliminated by building a common 
architected index characterized in that (1) it includes selected 
indexable 

elements each having sufficient associated pointers for environment 
and 

resource specifications to be accessed as stand-alone entities and 
(2) is 

structured to be handled by all users (application programs or 
processes) 

understanding the interchange protocol. Normal work with a file 
requires 
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reading the entire document file and building a process 1 own index. 
This 

requires excessive time and takes up storage which could be used for 
other 

purposes. By building an architected document index with associated 
pointers 

in turn associated with each indexable element, any desired element 
of the 

document can be readily addressed by many different users. 
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for environment and resource specifications to be accessed as 
stand-alone entities and (2) Is structured to be handled by all 
users (application programs or processes) understanding the 
interchange protocol. Normal work with a file requires reading 
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indexable element, any desired element of the document can be- 
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Description 

INTERCHANGE OBJECT 



BACKGROUND OF THE INVENTION 5 



Field of the Invention 

10 

The present invention generally relates to the 
specification of interchange document indices that 
provide data processing systems the necessary 
information to construct application dependent 
indices to an object oriented document database for 15 
random object retrieval. Processes may select 
portions of a document to build locally optimized 
database indices from the interchange form of a 
stored library document without processing the 
entire document. The invention also enhances 20 
document sharing through the elimination of repli- 
cated forms of the library document that occur when 
application processes build "process local copies. 0 

25 

Description of the Prior Art 

In data processing systems, there are the cor- 
relative problems of storing data in an efficient 
manner and later accessing the stored data, also in 30 
an efficient manner. The stored data constitutes a 
database the value of which is considerably en- 
hanced when it may be shared by multiple users or 
"processes" at the same time. In this context, a user 
or process may be considered an application 35 
program, and it is assumed here that the application 
programs which may access the data in the 
database may be diverse programs; that is, the 
programs are not identical. This in turn assumes a 
certain protocol in the storing, accessing and 40 
interpreting the data in the database which is 
observed by ail processes. 

There exist various database system architec- 
tures which implement various data structures, 
including the relational approach, the hierarchical 45 
approach and the network approach. Generally 
speaking, the relational approach presents the 
database to a user as a series of tables. The 
hierarchical approach presents the user with a view 
of the database as a tree structure having a "root" 50 
and a plurality of branching "nodes". A node 
connected to another node that is closest to the root 
is described as the "parent" and the other, as the 
"child". The network approach has some similarity to 
the hierarchical approach in that data is represented 55 
as (inked records. 

The subject invention uses a hierarchical ap- 
proach to database management and indices be- 
cause it mirrors the hierarchical structure of a 
compound interchange document containing both so 
architecture defined, e.g., a page, and user defined, 
e.g.. a paragraph, document elements. The general 
concepts of and the use of indices are well known in 



DATA BASE INDEX 

the data processing arts, and it Es assumed that 
those skilled In the art will be well versed in the 
same. Further background may be had by reference 
to the text book by Christopher J. Date entitled An 
Introduction to Database Systems, vol. 1, third 
edition, published 1981 by Addison-Wesley. 

The specific environment of the invention is in the 
field of a data stream architecture that allows 
processing applications the capability to inter- 
change document data from a sending application 
program to a receiving application program without 
knowing the receiver's processing capability. Nor- 
mal work with an object oriented interchange 
document requires reading the entire file and 
building a "process local" document copy together 
with its own index. This requires excessive time and 
takes up storage which could be used for other 
purposes. 



SUMMARY OF THE INVENTION 



It is therefore an object of the present invention to 
provide a method for eliminating a requirement for a 
private copy of the interchange document and the 
requirement of sequentially processing the entire 
document before local document indices can be 
built. 

According to the invention, the need for private 
copies of interchange documents is eliminated by 
the capability of specifying a document interchange 
Index that correlates to the interchange document 
elements. The index contains selected indexable 
elements each having sufficient associated pointers 
for environment and resource specifications to exist 
as stand-alone document entities and is structured 
to be handled by all users that understand the 
interchange document protocol. By building a 
common document Interchange element index with 
associated pointers In turn associated with each 
entry, any desired object element of the document 
can be readily accessed by many different users. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and 
advantages of the invention will be better under- 
stood from the following detailed description of a 
preferred embodiment of the invention with ref- 
erence to the drawings, in which: 

Figure 1 is a block diagram illustrating the 
current process of document Interchange; 

Figure 2 is a block diagram illustrating the 
process of document interchange according to 
the invention; 

Figure 3 is a block diagram showing the 
document index structure according to the 
invention; 

Figure 4 is a flow diagram showing the logic 
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of building a process local index from an 
interchange index; 

Figure 5 is a fiow diagram showing the logic 
of retrieving an index element from the process 
local index; 

Figure 6 is a flow diagram showing the logic 
of building an interchange index from the 
process local index; and 

Figure 7 is a fiow diagram showing the logic 
of building an interchange index from a sequen- 
tial data stream. 



DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT OF THE INVENTION 

Referring now to the drawings, and more particu- 
larly to Figure 1, there is shown a block diagram 
illustrating the current process of document inter- 
change. An interchange document 10 is stored in an 
interchange document library 12, which is typically 
contained on a central direct access storage device 
(DASD) accessed by a file server. Each of a plurality 
of users, here identified as Processes A through N f 
desire to access a document in the interchange 
document library. To do this, the interchange 
document accessed must first be copied to the 
user's local library. Thus, for example, Process A 
copies an interchange document to its local library 
14, Process B copies an interchange document to its 
local library 16, and Process N copies an interchange 
document to its local library 18. Each of these 
libraries may be a local DASD or a volume of a DASD 
allocated to the respective processes. The process 
of copying the interchange document from the 
interchange document library 12 to one of the 
process local libraries 14, 16 and 18 is accomplished 
by converting the interchange format to a private 
format specific to the local process. 

During or after the copy of the interchange 
document to the local library In the private format of 
the process, the process builds object element 
indices for the document. This is accomplished by 
interpreting the document content to detect ele- 
ments of the document to be indexed. Only when the 
document has been indexed by the process access- 
ing the document can the process finally begin the 
task of accessing elements within the document for 
processing, such as editing. 

The subject invention simplifies and streamlines 
the conventional process by adopting an Inter- 
change index for document interchange as shown In 
Figure 2. Here the Interchange document 20 is 
stored in an interchange document library 22, but in 
this case, each document in the interchange library 
is provided with an interchange index. As a result, It 
is not necessary for a process accessing the 
document to copy the interchange document to Its 
local process library in a format specific to the 
process. Instead, a process, such as Process A, 
simply builds its own index based on the document's 
interchange index, and using this local index, 
Process A may then access that part of the 
interchange document it needs to process. In like 
manner, Processes B through N build their own 



Indices based on the document's interchange index, 
and using their own local index, Processes B 
through N access that part of the document they 
need to process. 

5 Figure 3 illustrates, in block diagram form, a 
sample structure of element indices transmitted with 
an interchange document. The potential content of 
each element is depicted in box 31 to the right of 
element 32 labled "DOCUMENT". Each indexable 

10 element is wholly self-contained in that its process- 
ing environment, resources and element content are 
accessable via constructs defined and existing 
within the interchange index element definition. In 
the context of this invention, what is meant by the 

15 processing environment is, for example, formatting 
descriptions, what is meant by resources are fonts, 
overlays and the like, and what is meant by elements 
or data objects are such things as text, image and 
graphics data. 

20 For ease of understanding, Figure 3 is limited to 
displaying only the element hierarchy since an 
element's resource and environment constructs can 
be directly indicated in an index element definition. A 
processing application then "mirrors" the inter- 

25 change index element specification by hierarchically 
linking the document index elements and their 
associated content in a process local manner that is 
optimized for that particular application. Where many 
elements exist at a particular hierarchy level (e.g., 

30 pages one to fifty in the BODY 33 of a document), 
the process is free to implement any mechanism 
(e.g., a sorted page address table for each page In 
the BODY element 33) deemed acceptable by the 
application process. Byte offsets to document 

35 entities described by the interchange definition may 
be converted to process local addressing schemes 
that correlate to the storage device on which the 
Interchange document resides. For example, byte 
offsets can be transformed to direct access storage 

40 device (DASD) addresses. It is assumed that during 
process execution the application is cognizant of the 
hierarchical context in which current document 
activity is occurring. A process then may utilize the 
internal form of the interchange document index to 

45 randomly retrieve a document element such as 
paragraph two on page thirty-seven. The sample 
document shown in Figure 3 indicates that (for the 
ABSTRACT leg of the hierarchy) the DOCUMENT 32 
consists of a single ABSTRACT element 34 contain- 

50 Ing more than one PAGE. The PAGE 35 then 
contains more than one PARAGRAPH and a single 
FIGURE 36. The PARAGRAPH element 37 content Is 
then the TEXT DATA 38. A similar scenario can be 
stated for the BODY leg of the DOCUMENT 

55 hierarchy. 

Figure 4 is a flow diagram showing the logic of 
building process local indices from an interchange 
index. This process assumes a random input of 
elements from a data stream processor 40. The 

60 output of the data stream processor 40 is tested in 
decision block 41 to determine if index elements and 
associated content are found or referenced in the 
data stream. If not, the process exits to the data 
stream process at block 42. However, if index 

65 elements and content are encountered in the data 
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stream, then a local index is created In function 
block 43. The content of the elements In the index 
include their resources, other document elements 
and environment. For each new element in the index, 
a test is made in decision block 44 to determine if a 
parent element exists. See again the hierarchical 
structure of Figure 3. If not. the new element is 
placed in a "waiting for parent list" in function block 
45: otherwise, the new element is linked from its 
parent element in function block 46. A test is next 
made in decision block 47 to determine if children 
elements exist for new the elements in the "waiting 
for parent list". If so, the new parent element is 
linked to the children elements In function block 48 
before the process exits to the data stream process; 
otherwise, the process exits directly to the data 
stream process in function block 42. 

The following pseudo code, written in Program 
Design Language (PDL), implements the logic of the 
flow diagram shown in Figure 4. It is assumed that an 
interchange document has just been received by an 
application that wishes to modify certain sections of 
the document without sequentially processing the 
entire document to establish the processing envi- 
ronment for the changed document portions. The 
application then uses the interchange document 
index elements so it can access the sections to be 
modified. It must build its internal element index from 
the interchange element index and, 
IF an Index Element and its associated Content are 
Encountered in the data stream, THEN: 

CREATE the process local internal form ident- 
ifying the element and its content (i.e., objects, 
resources and environment). The Internal process 
form of the interchange element index is dependent 
on the performance and library access characteris- 
tics of the particular application. 

IF a parent index element exists for the new index 
element, THEN: 

LINK the new index element to the parent index 
element in order to parallel the Index element 
hierarchy defined in the interchange data 
stream. For example, this maintains the docu- 
ment hierarchy relationship for indexable ele- 
ments as shown in Figure 3. 
ELSE: 

PLACE the new index element in a "waiting for 
parent list*. Note that the index element 
specifications in the interchange data stream 
are not required to appear in any specific 
physical sequence. The description of an index 
element permits an application process to 
construct an index element hierarchy as show 
in Figure 3. 

IF unlinked children index elements exist for the 
'new" index element in the "waiting for parent 
list". THEN: 

LINK the new index element as the parent to the 

children index element(s). 

ELSE: 

EXIT to the process that interprets the inter- 
change data stream Structured Fields. 
ENDIF: 

ENDIF: ELSE: 



EXIT to the process that interprets the inter- 
change data stream Structured Fields. ENDIF: 

Figure 5 is a flow diagram showing the logic of the 
process of retrieving an index element from a 
5 process local index. The process begins in function 
block 50 which cails the operation of locating the 
requested element on the document interchange 
library using the internal process index in function 
block 51. A test is made in decision block 52 to 

10 determine if the index element is valid. If not, an error 
return code is set to the invoking process in function 
block 53 before a return is made to the index 
element retrieval process in function block 54. On 
the other hand, if the Index element is valid, the 

15 element's content is retrieved from the document 
interchange library in function block 55. Then, the 
resource, object and processing environment for 
the element is established in function block 56 
before a return to the index element retrieval 

20 process is made in function block 54. 

The following pseudo code, written in Program 
Design Language (PDL), implements the logic of the 
the flow diagram shown in Figure 5. It is assumed 
that the processing application has requested 

25 access to a document index element (e.g., LIST 
ITEM three in PARAGRAPH one on PAGE twelve in 
the BODY section of a document) that needs to be 
updated. The processing application then, knowing 
the hierarchical document context in which the 

30 request was generated, searches its internal form of 
the document index and, 

IF the Index Element and its associated Content 
exist in the processes' internal document element 
index, THEN: 

35 RETRIEVE the index element's content from the 
interchange document library using the internal 
element index that it created for the index elements 
defined in the interchange document. 
ESTABLISH the resource, object and processing 

40 environment associated with the requested docu- 
ment index element. In the example stated pre- 
viously, a resource (e.g., font) might be necessary to 
display the text data (object) in the correct area 
(formatting environment) on a screen. 

45 RETURN to the processing application. ELSE: 

SET an error code indicating that the requested 
document index element does not exist. 
RETURN to the processing application. ENDIF: 
The flow diagram shown in Figure 6 shows the 

50 logic of the process for building an interchange 
index from a process local index. The process 
begins with a call to the interchange data stream 
build function in block 60. A test is made in decision 
block 61 to determine if the last document index 

55 element has been processed. If it was, a return Is 
made to the interchange data stream build function 
in function block 62; otherwise, another test is made 
in decision block 63 to determine if this element is 
the last element of the document leg. By leg, what is 

60 meant is again the hierachical structure shown in 
Figure 3. If the test in decision block 63 is positive, 
the index element search is adjusted to the next 
branch in the document hierarchy in function block 
64; if negative or after the adjustment of the search 

65 in function block 64, the next internal index element 



4 



6/20/06, EAST Version: 2.0.3.0 



7 



EP 0 332 556 A2 



8 



within the document hierarchy is retrieved in func- 
tion block 65. Then, the interchange form of index 
element and its associated content is created from 
the internal index in function block 66 before the 
process loops back to decision block 61. 

The following pseudo code, written in Program 
Design Language (PDL), represents an implementa- 
tion of the logic of the flow diagram of Figure 6. It is 
assumed that a processing application wants to. 
transmit the document it has been updating to an 
editor for inclusion of some recently added pages 
created in another department. The application can 
then create the interchange document element 
index from its internal form in order to facilitate both 
the receiver's processing requirements and its own 
processing requirements whenever the edited docu- 
ment is returned. IF the last document index element 
has been processed, THEN: 

RETURN to the interchange data stream build- 
function. ELSE: 

IF the last document index element within a 
particular hierarchal leg (branch) has not been 
processed, THEN: 

RETRIEVE the next internal index element 
within the particular leg of the element hier- 
archy. For example, in Figure 3 one leg of the 
ABSTRACT-DOCUMENT hierarchy is AB- 
STRACT, PAGES, PARAGRAPHS, and TEXT 
DATA. The other leg of the DOCUMENT-AB- 
STRACT hierarchy is ABSTRACT, PAGES and 
FIGURE. 

CREATE the interchange form of the index 
element and its content from the application's 
internal format. 
ELSE: 

ADJUST the process* internal element search 
to the next leg in the document index element 
hierarchy. For example, if the last TEXT DATA 
element in the DOCUMENT, BODY, PAGES, 
PARAGRAPHS, LISTS, TEXT DATA leg has just 
been processed, then the index element search 
would resume at the DOCUMENT, BODY, 
PAGES, FIGURES leg. 

RETRIEVE the next internal index element 
within the particular leg of the element hier- 
archy. 

CREATE the interchange form of the index 
element and its content from the application's 
internal format. 

ENDIF: ENDIF: 

Figure 7 is a flow diagram of the logic for building 
an interchange index from a sequential data stream. 
The process begins by determining In decision block 
70 whether the calling process wants to build 
interchange index elements. If not, the process 
returns to the interchange data stream build function 
in block 71; otherwise, the current state of the 
resources, objects and environementfor processing 
is established for the next document index element 
in function block 72. The next document element 
occurring in the data stream is processed in function 
block 73, and then in function block 74, the 
interchange form of the Index element and its 
associated content are created from the current 



state document values. A test is then made in 
decision block 75 to determine if the end of the 
document data stream has been reached. If not, the 
process loops back to function block 72, but if so, a 

5 return is made to the Interchange data stream build 
function in block 71 . 

The following pseudo code, written in Program 
Design Language (PDL), implements the logic of the 
flow diagram of Figure 7. It is assumed that a 

10 processing application wants to build interchange 
index elements from its internal form of the docu- 
ment data stream which does not contain internal 
index elements. 

IF the application does not want to build the 
15 interchange form of the document's elements, 
THEN: 

RETURN to the interchange data stream build 
function. ELSE: 

ESTABLISH the current state for resources, objects 
20 and processing environment in order to preserve 
this information for the next document index 
element occurring in the data stream. 
PROCESS the next document index element occur- 
ring sequentially in the data stream. 
25 CREATE the interchange form of the index element 
and Its content from the application's current state 
information that describes the current state for the 
particular index element. 

IF the end of the sequential document data stearm 
30 occurs, THEN: 

RETURN to the interchange data stream build 
function. 

ELSE: 
35 ENDIF: ENDIF: 

By providing an interchange document index, the 
requirement for a private copy of Interchange 
document files is eliminated. This simplifies and 
streamlines the process of document interchange 
40 processing with a resultant elimination of overhead 
expense to each process accessing the document 
and an increase in the processing speed. 

While the invention has been described in terms of 
a single preferred embodiment, those skilled in the 
45 art will recognize that the invention can be practice 
with modification within the spirit and scope of the 
appended claims. 



50 Claims 

1. A method of eliminating a requirement of a 
private copy of interchange document files by a 
plurality of diverse application programs in a 

55 computer system, said method comprising the 

step of building and maintaining a common 
document interchange index during file creation 
and modification with each document element 
being capable of standing alone in an applica- 

60 tion processing environment thereby allowing 

any of said application programs to select 
portions of a document and build a locally 
optimized database index which is application 
dependent without processing the entire docu- 

65 ment 
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2. The method according to claim 1 a data 
stream process wherein a local index is built 
from said interchange index comprising the 
steps of: 

detecting index elements in a data stream 
containing said interchange index and creating 
a local index of document element content 
including resources, data objects and process- 
ing environment; 

testing each index element to determine if a 
parent element in a hierarchical structure of 
elements exists and, if not, placing the index 
element in a list file, otherwise, linking the index 
element to the parent element; and 
testing each index element in said list file to 
determine if children elements exist for the 
index element and, if so, linking the index 
element in the list file to the children elements 
before exiting to said data stream process, 
otherwise, exiting directly to the data stream 
process thereby building a hierarchical process 
local index. 

3. The method according to claim 2 wherein 
an index element is retrieved from the process 
local index comprising the steps of: 

using the process local index to locate a 
requested element on the document file; 
retrieving the requested element from the 
document file; and 

establishing the resource, data object and 
processing environment for the retrieved ele- 
ment before returning to the index element 
retrieval process. 

4. The method according to claim 2 including 
an interchange data stream build function 
wherein in an interchange index for trans- 
mission of a document to another application 
program is built from the process local index 
comprising the steps of: 

for each element In the process local index, 
determining whether the element is the last 
document index element to be processed and, 
if so, making a return to the interchange data 
stream build function; 

otherwise, testing each element to determine if 
it is the last element of a document leg in the 
hierarchical local process index and, if it is, 
adjusting an index element search to another 
branch in the document hierarchy before re- 
trieving a next internal index element within the 
document hierarchy, but if it is not, then 
retrieving a next internal index element within 
the document hierarchy; 
and 

creating an interchange form of index element 
and content from the process local index before 
repeating the process for the next document 
index element until the last document index 
element is processed. 

5. The method according to claim 1 wherein 
the step of building and maintaining a document 
interchange index from a sequential data 
stream defining said document comprises the 
steps of: 

establishing a current state of resources, data 



objects and processing environment for each 
document index element; and 
creating an interchange form of index element 
and content from the current state of each said 
5 document index element until the end of said 

data stream is reached. 
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